Frame Relay Forum Technical Committee 
Contribution

Title:  Proposal to Begin a Frame Relay Security Implementation Agreement

Contact:	David A. Sinicrope
IBM Corporation
800 Park Offices Drive   CE6A/664   
Research Triangle Park, NC 27709 USA
+1 (919) 254-1207
FAX:  +1 (919) 254-5483
Internet/e-mail:  david@raleigh.ibm.com

Date:	September 8-10, 1997

Location:	Atlanta, Georgia

Distribution:	Participants in the Frame Relay Forum Technical Committee. 

Abstract:	This contribution identifies the need for security protocols on frame relay connections.  It proposes new work to be started on an implementation agreement for frame relay security (FRF.sec).  It also proposes requirements to direct contributions and discussion.

Notice:	This contribution has been prepared to assist the Frame Relay Forum.  This document is offered to the Forum as a basis for discussion and is not a binding proposal on IBM, any of its subsidiaries or any other company.  The statements are subject to change in form and content after further study.  Specifically, IBM reserves the right to add to, amend or modify the statements contained herein.

1.	
Introduction
Data security over frame relay is an issue that has come up periodically over the past years.  For corporations that use frame relay to transport their web and non-mission critical traffic, this was a low-priority concern that could be overlooked.  Now that the frame relay industry is targeting transport of corporate mission critical traffic, the security concern is raised more frequently and must be addressed.
Frame relay offers users tremendous flexibility and cost savings over leased line solutions, however, most frame relay data payload is passed as “clear text”, assuming no tampering and with little to no authentication of the peer devices on the virtual circuit.  To users such as banking and financial institutions, this is unacceptable, and is less function than they can get with leased lines using line encryption or PPP.  As users begin to demand security function of their frame relay access equipment, it is crucial to establish an implementation agreement to provide the security features the users are requesting, and still maintain interoperability between vendor devices.
2.	Problems/Issues
Many applications and some protocols offer security functions today. So why do we need security at the frame relay layer?  The increased popularity of the web and corporate intranets, the legacy SNA networks, and the push toward network consolidation means that corporations still have predominately multiprotoocol networks.  These networks are transporting traffic from applications and protocols that may or may not be protected.  For example with bridged LAN traffic, or RFC 1490 traffic some traffic streams may be protected and others may not. It is difficult to determine without considering the source of the traffic and the network protocols used to transport it.
Administratively, security on a multiprotocol network is a nightmare.  Multiple protocols and applications all have their own key management and security functions.  Security function at the frame relay layer, alleviates many of these issues, if not totally, then at least across the WAN where many users have the most concern.
Most issues with security fall into 3 major categories which should be addressed:
1.	Authentication – Proving that the peer device is who they claim to be.
2.	Data Integrity – Ensuring that the data has not been tampered with.
3.	Encryption – Encoding the data such that it is not intelligible to anyone but the intended recipient.
Some of these issues are addressed with features already found in protocols and applications.  The security features of frame relay must not interfere, and should compliment, the security features of the upper layer protocols.  For example, an WAN edge device such as a router or FRAD may not be aware that a host on one of its LANs is transporting data using IP security.  Re-encrypting this traffic would result in redundancy and a waste of resources.  However, other traffic sharing the same virtual circuit (e.g., bridged frames, IPX, etc.) may be delivered to the FRAD in the clear and should be encrypted before it is transmitted over the frame relay network.
3.	Proposed Actions
This contribution proposes that the Frame Relay Forum begin work on an implementation agreement to address frame relay security.  The proposed requirements below can be used as a starting point for discussion and contributions.
4.	Proposed REQUIREMENTS and direction
•	The work on security should address the 3 major issues presented above, (i.e., Encryption, Authentication and Data Integrity).
•	Initial Requirements:
1.	Compatible with current frame relay traffic.  For example, it must work with FRF.3.1, voice traffic, data compression, fragmentation, etc.
2.	Able to be selectively applied to a subset of the VC traffic, if applicable
3.	It should be simple and capitalize on function already available in the industry. (e.g., PPP encryption, IP Sec, RSA, DES, etc.)
4.	A control/negotiation protocol.  For example, similar to the mode 1/mode 2 scheme used for Data Compression Protocol